home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group92c.txt / 000075_icon-group-sender _Fri Nov 6 04:40:10 1992.msg < prev    next >
Internet Message Format  |  1993-01-04  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Thu, 12 Nov 1992 05:29:17 MST
  2. Date: 6 Nov 92 04:40:10 GMT
  3. From: srt@arizona.edu  (Scott R. Trappe)
  4. Subject: Rationale for sortf() second argument?
  5. Message-Id: <25952@optima.cs.arizona.edu>
  6. Sender: icon-group-request@cs.arizona.edu
  7. To: icon-group@cs.arizona.edu
  8. Status: R
  9. Errors-To: icon-group-errors@cs.arizona.edu
  10.  
  11. The sortf() function in Icon V8.7 is defined as:
  12.  
  13.      sortf(X,i)  Produces a sorted list of the elements of X. The
  14.                  results are similar to those of sort(X,i),
  15.                  except that among lists and among records,
  16.                  structure values are ordered by comparing their
  17.                  ith fields.
  18.  
  19. Can someone explain to me why the second argument to the sortf() function is
  20. an integer index of the field in the record to sort on, instead of a string
  21. containing the field name?  As defined, this function seems to be very
  22. dangerous, since adding, deleting, or re-ordering fields in a record could
  23. change which field is used as the key.  The programmer must manually inspect
  24. each use of sortf() and verify that either it is not being used on data
  25. structures containing the affected record type, or that the field index is
  26. unaffected by the change.
  27.  
  28. It would seem that specifying the field name as a string is far safer; it makes
  29. it obvious which field is used as the key, makes the program insensitive to
  30. adding or re-ordering fields in the record, and should the field be deleted,
  31. could result in a run-time error.  It would seem to also improve program
  32. readability, since in the typical case the field name would be a literal string
  33. in the sortf() function.  As it stands now, one has to go find the record
  34. declaration and count the fields to find out which field is the key.
  35.  
  36. This is even more problematical if one is using an Icon pre-processor such as
  37. Idol that adds extra fields to the BEGINNING of the record: without knowledge
  38. of the transformations that the preprocessor makes, it is impossible to use the
  39. sortf() function.  Worse, changes to the pre-processor could silently break
  40. "correct" code.
  41.  
  42. There seems to me to be precedent in Icon for supplying language identifiers
  43. in strings; witness the proc() and args() functions.  Indeed, in the very same
  44. report where the sortf() function is described, there is a description of a
  45. new feature whereby field selection can be done with a string operand, for
  46. example:
  47.  
  48.     record.["field1"]
  49.  
  50. can be used to mean:
  51.  
  52.     record.field1
  53.  
  54. Scott Trappe
  55.